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REMARKS 

Claims 1-10 and 13-30 are allowable 

Regarding the rejection of claims 1-10 and 13-30 under 35 U.S.C § 103(a) ove:: RFC 
2516 in view of Iwalcata (US Pub. 2002/0095299) on page 2 of the Office Action, claims 1 and 6 
have been amended to overcome these rejections. Claim 1 has been amended to include the 
element "generating a device identifier code that specifically identifies a product model of a 
customer premises equipment device in response to receiving a point-to-point over Ethernet 
(PPPoE) packet communicated over the distributed network." Claim 1 as amended furiher 
recites the element broadcasting a point-to-point over Ethernet (PPPoE) active discoveiy 
initiation (PADI) packet, wherein the PPPoE active discovery initiation (PADI) packet includes a 
tag, wherein the tag is based on the device identifier code." These elements are not taught or 
suggested by RFC 25 16 or Iwakata, Furthermore, these elements are not taught or suggested by 
a combination of the two references. 

RFC 2516 discloses a standard method for transporting multiprotocol datagrams over 
point-to-point links. At page 2 of the Office Action, it is stated that "RFC 2516 teaches 
generating a device identifier code in response to receiving a point-to-point over Ethernet 
(PPPoE) packet communicated over the distributed network." The Office Action further states 
that the "device identifier code" disclosed in RFC 2516 is the "Ethernet MAC address of the 
source device " Claim 1, as amended, recites that the device identifier "specifically identifies a 
product model of a customer premises equipment device." The Ethernet MAC address cited by 
the Office Action does not specifically identify a product model of a customer premises 
equipment device. Furthermore, as stated in the Office Action at p. 3, RFCA 2516 does not 
disclose a tag included in a PADI packet, wherein the tag is based on the device identifier code. 
Accordingly, RFC 25 16 does not teach or suggest each and every element of claim 1 . 

Iwakata discloses a customer information control system for controlling persond 
information and product identification information for electronic equipment belonging to a 
customer. The system disclosed by Iwakata includes a client machine belonging to a customer 
and a host machine that registers customer information. Iwakata [0070]. The client machine 
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includes a product identification information storing unit and a data transmit/receive urit for 
sending customer management information to the host machine. Iwakata [0071]. Product 
identification information is transmitted to the host machine after the host machine or client 
machine has initiated a communication session. Iwakata [0083]. There is no teaching or 
suggestion by Iwakata that the client machine generates a device identifier code that specifically 
identifies a product model of a customer premises equipment device in response to receiving a 
point-to-point over Ethernet (PPPoE) packet communicated over the distributed network- 
Iwakata nowhere teaches or suggests the use of Ethernet or PPoE packets for communication 
between the host and client machines. 

Furthermore, Iwakata does not teach or disclose "broadcasting a point-to-point over 
Ethernet (PPPoE) active discovery initiation (PADI) packet, wherein the PPPoE active discovery 
initiation (PADI) packet includes a tag, wherein the tag is based on the device identifier code" as 
recited in claim 1. As noted above, Iwakata does not teach or suggest the use of Ethernet or 
PPoE packets for communication between the host and client machines. In addition, Iwakata 
does not disclose embedding product information in an Ethernet packet tag. Instead, Iwakata 
discloses that "personal information is combined with the read out product information as a set 
of customer management information CMI which is sent to the host machine " Iwakata [0087]. 
Nowhere does Iwakata teach or suggest placing this information into a PADI packet including a 
tag. 

Accordingly, Iwakata does not teach or disclose at least two elements of claim 1. 
Furthermore, as explained above, these elements are not taught or disclosed by RFC 25 16. 
Accordingly, the combination of these two references does not teach or suggest each and every 
limitation of claim 1 . 

With respect to claims 2-5, Iwakata and RFC 2516 fail to teach or suggest each and every 
element of these claims, at least by virtue of their dependency from claim 1 . 

With regards to claim 6, die claim, as amended, recites the following element: 
"generatiAg a device identifier code based on the tag in response to receiving the PPPoE active 
discovery packet." Furthermore, claim 6 recites that the tag upon which the device identifier 
code is based "specifically identifies a product model of a customer premises equipment (CPE) 
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device." As discussed above with respect to claim 1, neither RFC 25 16 nor Iwakata tefich or 
suggest a device identifier code that specifically identifies a product model of a customer 
premises equipment device. 

Furthermore, neither RFC 25 1 6 nor Iwakata teach or suggest "sending a point-to-point 
over Ethernet (PPPoE) active discovery packet, wherein the PPPoE active discovery packet 
includes a tag that specifically identifies a product model of a customer premises equipment 
(CPE) device" as recited in claim 6. As stated in the Office Action at p. 4, RFC 2516 fails to 
specify this element Furthermore, Iwakata fails to teach or suggest the use of PPPoE active 
discovery packets including a tag that specifically identifies a product model of a CPE device. 
As described previously, Iwakata instead discloses combining personal information wiih product 
identification information into customer management information CMI and sending this 
combined information. Accordingly, RFC 2516 and Iwakata, alone or in combination, fail to 
teach or suggest each and every element of claim 6. 

With respect to claims 7-10 and 13-15, claim 7 has been cancelled without prejudice or 
disclaimer. Claims 8-10 and 13-15 depend from claim 6. Therefore, RCF 2516 and Iwakata do 
not teach or suggest every element of claims 8-10 and 13-15, at least by virtue of their 
dependency on claim 6. 

In regards to claim 16, the claim includes the following element: deceiving a point-to- 
point over Ethernet (PPPoE) active discovery packet, wherein the PPPoE active discovery packet 
includes a tag that identifies a product model of a customer premises equipment device." As 
described above, neither RFC 25 16 nor Iwakata teach or suggest a tag that identifies a jjroduct 
model of a CPE device included in a PPPoE active discovery packet. Accordingly, RFC 25 1 6 
and Iwakata fail to teach or suggest every element of claim 16, and claim 16 is also allowable. 

Claims 17-20 depend from claim 16. Iwakata and RFC 2516 fail to teach or suggest each 
and every element of these claims, at least by virtue of their dependency from claim 1 6. 

With respect to claim 21, the claim recites "a module coupled to the network interface, 
said module configured to transmit a point-to-point over Ethernet (PPPoE) active discovery 
packet including a tag, the tag comprising a device identifier field that uniquely identifies a CPE 
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product model." As explained above, neither RFC 2516 nor Iwakata teach or suggest a tag that 
comprises a device identifier field that uniquely identifies a CPE product model. Furthermore, 
neither RFC 2516 nor Iwakata teach or suggest a module configured to transmit a PPPoE active 
discovery packet including such a tag. Therefore, RFC 25 16 and Iwakata fail to teach or suggest 
each and every limitation of claim 21 . 

Claims 22 and 23 depend from claim 2L Iwakata and RFC 25 1 6 fail to teach or suggest 
each and every element of these claims, at least by virtue of their dependency from claim 2 1 . 

Claim 24 recites "an access concentrator configured to receive an active discovery packet 
having a tag comprising a device identifier field." The claim further recites that the "device 
identifier field uniquely identifies a product model associated with the communications device." 
As set forth above, RFC 251 6 and Iwakata each fail to teach or suggest the use of a tag in a 
discovery packet that uniquely identifies a product model associated with a communications 
device. Moreover, both RFC 2516 and Iwakata fail to teach or suggest an access concentrator 
configured to receive an active discovery packet having such a tag. Accordingly, RFC 2516 and 
Iwakata fail to teach or suggest each and every limitation of claim 24. 

Claims 25 and 26 depend from claim 24. Iwakata and RFC 2516 fail to teach or suggest 
each and every element of these claims, at least by virtue of their dependency from claim 24. 

With respect to claim 27, the claim recites the following element "an Ethertype payload 
field including a host-uniq tag value indicating a model type of a digital switching device " As 
explained above, neither RFC 251 6 nor Iwakata teach or suggest a tag value indicating a model 
type of a digital switching device. Furthermore, neither RFC2516 nor Iwakata teach or suggest 
an Ethertype payload field including such a tag. Accordingly, RFC 25 1 6 and Iwakata fail to 
teach or suggest each and every limitation of claim 27. 

Claims 28-30 depend from claim 27. Iwakata and RFC 25 16 fail to teach or suggest each 
and every element of these claims, at least by virtue of their dependency from claim 27. 
Furthermore, claim 30 recites that "the model type of the digital switching device is a nine bit 
binary device identifier code associated with customer premises equipment." Neither RFC 2516 
nor Iwakata teach or suggest the use of a nine bit binary device identifier code associated with 
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customer premises equipment. Accordingly, RFC 2516 and Iwakata fail to teach or suggest each 
and every limitation of claim 30. 

Furthermore, with respect to each of the claims discussed above, there is no suggestion in 
either RFC 2516 or Iwakata to combine the two references. RFC 2516 -'provides a standard 
method for transporting multi-protocol datagrams over point-to-point links." RFC 25 1 6, p. 1. 
Iwakata, in contrast, is concerned with a customer information control system of electronic 
equipment for controlling personal information and product identifications information of the 
electronic equipment belonging to a customer. Iwakata, p. 1. Furthermore, the system of Iwakata 
discloses a simple host to client direct connection. A person of ordinary skill would not look to a 
multi-protocol datagram standard, such as the point-to-point over Ethernet multi-protocol 
standard of RFC 2516 to implement a simple data connection between a host and cliem. As 
such, Iwakata does not address and its teachings of a single host-client connection are 
inconsistent with transporting multi-protocol datagrams over point-to-point links. Accordingly, 
there is no motivation, teaching or suggestion for one of skill in the art to combine the RFC 25 1 6 
and Iwakata references. 

For at least the reasons set forth above, it is respectfully submitted that the obviousness 
rejection of claims 1-10 and 13-30 is improper and withdrawal of this rejection therefore is 
respectfully requested. 

Claims 11 and 12 are allowable 

Regarding 1he rejection of claims U-12 under 35 U>S.C, § 1 03(a) over RFC 25 16 in view 
of Iwakata as applied to claim 6 above, and further in view of Yusko et al. (US Pub 
2004/0071 133) on page 1 1 of the Office Action, claim 6, from which claims 1 1 and 12 depend, 
has been amended to overcome these rejections. 

Yusko discloses a system for intelligent PPPoE initialization. Yusko, p.l . Yu&co fails to 
teach or suggest sending a point-to-point over Ethernet (PPPoE) active discovery packet, 
wherein the PPPoE active discovery packet includes a tag that specifically identifies a jwoduct 
model of a customer premises equipment (CPE) device, as recited by claim 6. Furthermore, 
Yusko fails to teach or suggest generating a device identifier code based on the tag in response to 
receiving the PPPoE active discovery packet, as recited by claim 6. As explained above, these 
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elements are also not taught or disclosed by Iwakata or RFC 25 1 6. Accordingly, even if there 
were a suggestion to combine the Yusko, Iwakata, and RFC 25 16 references, the references in 
combination fail to disclose each and every element of claims 1 1 and 12, at least by virtue of 
theix dependence on claim 6. 

Furthermore, there is no suggestion in the Yusko and Iwakata references that the 
references should be combined. Yusko discloses a system for intelligent PPPoE initialization. 
Iwakata is concerned with a customer information control system of electronic equipment for 
controlling personal information and product identifications information of the electroric 
equipment belonging to a customer. Iwakata, p. 1. Accordingly, each of the cited references 
addresses a different subject and a different problem, Thus there is no motivation, teaching or 
suggestion for one of skill in the art to combine the references. 

For at least the reasons set forth above, it is respectfully submitted that the obviousness 
rejection of claims 1 1 and 12 is improper and withdrawal of this rejectioa therefore is 
respectfully requested. 

Claims 31 to 35 are allowable 

Claims 31 to 35 have been added. Applicants submit that these claims are not taught or 
suggested by the prior art and are allowable. 

CONCLUSION 

Since all of the independent claims are allowable, all of the dependent claims are likewise 
allowable* 

Applicants respectfully submit that the present application is in condition for allowance. 
Accordingly, the Examiner is requested to issue a Notice of Allowance for all pending claims. 
If, for any reason, the Office is unable to allow the Application on the next Office Action, and 
believes a telephone interview would be helpful, the Examiner is respectfully requested to 
contact the undersigned attorney or agent. 
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The Commissioner is hereby authorized to charge any fees that may be required, or credit 
any overpayment, to Deposit Account Number 50-2469. 

Respectfully submitted, 




Date Jefffey G. Toler; Reg. No. 38,342 

Attorney for Applicants) 
TOLER, LARSON & ABEL, L.L.P. 
5000 Plaza On The Lake, Suite 265 
Austin, Texas 78746 
(512) 327-5515 (phone) 
(512) 327-5452 (fax) 
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